In a typical scenario, a plurality of services running on a server node may need to be able to access to the cache memory at the same time. A fundamental requirement of the server node is that it should always read a consistent snapshot taken of the data on the machine or server node. A further requirement is that the data on the cache may be efficiently refreshed which means that once an object was accessed, any further access to that object may not require searching for it again. In terms of complexity, this means that once an object is retrieved, further accesses are in the order of O(1).
In a case that the cache memory is to be shared (instead of having a separate cache for each service which is inefficient), it is desirable to resolve any potential conflict between operations. Specifically, if one service writes to a specific address on the shared cache, another service cannot read the data as it is being changed and by the end of the read operation, some of the data is no longer valid due to the simultaneous write operation by different service.
A solution known in the art for the aforementioned condition, is to resolve conflicting operations on a shared resource is the use of a lock (also known as mutex) that prevents one service from accessing the shared resource (e.g. cache) whenever another service is already accessing it. Thus the operations of the services over the shared cache are mutually exclusive. Locks affect the performance of the system and may increase latency and may sometimes lead to starvation of some services.
While some lock-free mechanisms are known in the art relating to several types of resources, none of the existing technologies known in the industry or academia suggests a lock free shared memory between processes (as opposed to shared memory between threads).